Warum Compliance deine Releases immer wieder verlangsamt (und was du als Erstes ändern solltest)

Ein Team liefert den größten Teil des Jahres in gleichmäßigem Tempo aus. Dann rückt ein Audit näher, und die Auslieferung verlangsamt sich. Entwickler werden von der Entwicklung von Features abgezogen, um das Audit zu unterstützen, und erstellen die Konfigurationsexporte, Protokolle und Umgebungsprüfungen, auf denen die Nachweise basieren. Die Verlangsamung dauert so lange wie das Audit selbst.

Man könnte das leicht so interpretieren, dass das Team schneller arbeiten oder größer sein müsste. Meistens trifft aber keines von beiden zu. Die Verzögerung entsteht durch manuelle Compliance-Arbeit, die mit jedem Release einhergeht, und mehr Personal für diese Arbeit einzustellen, führt nur dazu, dass noch mehr davon anfällt.

Den Umfang unterschätzt man leicht. Im ersten Jahr des SOC-2-Prozesses werden üblicherweise zwischen 100 und 500 Stunden Entwicklungszeit für Compliance-Aufgaben aufgewendet, die der Produkt-Roadmap entzogen werden – Kosten, die nie als Rechnung erscheinen, sondern in Form von features bezahlt werden, die erst später ausgeliefert werden. Die Arbeit selbst ist das Problem, nicht die Leute, die sie erledigen, und das meiste davon existiert nur, weil die Compliance manuell nachgewiesen wird, Release für Release.

Der Engpass liegt nicht in der Geschwindigkeit deines Teams

Wichtigste Erkenntnis: Die Auslieferung verlangsamt sich vor Audits, weil Entwickler für manuelle Nachweisarbeiten abgezogen werden – nicht, weil sie zu langsam programmieren.

Wenn sich Release-Zyklen aufgrund von PCI-DSS- oder SOC-2-Verpflichtungen verlangsamen, liegt das Problem selten darin, wie schnell Entwickler programmieren. Es ist vielmehr die Arbeit, die erforderlich ist, um nachzuweisen, dass der Code unter kontrollierten Bedingungen veröffentlicht wurde.

In der Praxis wirkt ein Audit-Zeitfenster wie ein Feature Freeze. Deine erfahrenen Entwickler stellen die Auslieferung ein und beginnen, Nachweise zusammenzustellen: Sie exportieren Pull-Request-Verläufe, um zu zeigen, dass Änderungen geprüft wurden, rufen Zugriffsprotokolle ab, um nachzuweisen, wer auf die Produktionsumgebung zugreifen konnte, erstellen Screenshots der Konfiguration, um zu belegen, dass eine Kontrolle vorhanden war, und bestätigen, dass die Staging-Umgebung, die ein Prüfer betrachtet, tatsächlich mit dem übereinstimmt, was ausgeliefert wurde. Keine dieser Arbeiten bringt eine Funktion voran. Sie wird von denselben Leuten erledigt, auf die du dich bei der Umsetzung der Roadmap verlässt, und sie wird in jedem Audit-Zyklus fällig.

Deshalb fühlt sich die Verlangsamung wie ein Teamproblem an, obwohl es eigentlich ein Prozessproblem ist. Das Team bringt keine schlechten Leistungen. Es wird lediglich von der Auslieferung abgezogen, um Compliance-Arbeit manuell zu erledigen.

Warum die Audit-Vorbereitung Releases verlangsamt

Das Wichtigste auf einen Blick: Die Verzögerung entsteht durch manuelle, sich wiederholende Nachweisarbeiten und den Abgleich der Umgebungen – allesamt Prozesskosten und keine technischen Fehler.

Für die meisten Unternehmen ist das kein einmaliges Ereignis im Jahr. Im „2026 Compliance Benchmark Report“ von A-LIGN gaben 97 % der Unternehmen an, mindestens zwei Audits oder Bewertungen pro Jahr durchzuführen, und eine frühere Studie des Unternehmens ergab, dass fast zwei Drittel mindestens drei Monate im Jahr mit der Vorbereitung darauf verbringen. Die Verzögerung entsteht durch eine Handvoll spezifischer, sich wiederholender Aufgaben, und jede davon ist eher ein Artefakt des Prozesses als ein Zeichen für ein schwaches Team.

• Das Sammeln von Belegen erfolgt manuell und wiederholt sich. Der Prüfer verlangt eine Stichprobe der Änderungen aus dem betreffenden Zeitraum und den Nachweis, dass jede davon vor der Veröffentlichung überprüft wurde. Jemand stellt das dann aus dem Pull-Request-Verlauf, Ticket-Exporten und Screenshots neu zusammen, da kein einzelnes System dies in Echtzeit aufgezeichnet hat. Im nächsten Zyklus fängt das gleiche Zusammensetzen wieder von vorne an.
• Umgebungen driften auseinander, daher ist es schwer, die Übereinstimmung nachzuweisen. Der Prüfer bittet dich, nachzuweisen, dass das, was du getestet hast, auch das ist, was du ausgeliefert hast. Wenn sich Staging- und Produktionsumgebung unbemerkt auseinanderentwickelt haben – hier eine Bibliotheksversion, dort ein Konfigurationsflag –, wird die Beantwortung dieser Frage zu einem ganzen Tag voller Nachforschungen, bevor du überhaupt antworten kannst.
• Kontrollen werden manuell nachgewiesen. Wenn du auf einer reinen Infrastruktur aufbaust, bist du für die Absicherung des Betriebssystems, das Patchen und die Netzwerkisolierung verantwortlich – und musst die Nachweise dafür alles selbst erbringen.
• Die Rückverfolgbarkeit von Änderungen wird im Nachhinein rekonstruiert. Wer was wann und warum geändert hat, wird aus Erinnerungen und verstreuten Tickets zusammengesetzt, anstatt aus einem einzigen, zuverlässigen Verlauf abgelesen zu werden.
• Der Prüfungsumfang ist größer, als er sein müsste. Ohne eine klare Abgrenzung zwischen dem, wofür die Plattform verantwortlich ist, und dem, wofür deine Anwendung verantwortlich ist, bleiben Kontrollen, für die eine Plattform im Rahmen eines Modells der geteilten Verantwortung zuständig sein könnte – wie Netzwerksegmentierung, Absicherung der Infrastruktur und physische Sicherheit – weiterhin in deinem Prüfungsumfang.

All das sind Folgen davon, dass die Compliance-Arbeit am falschen Ort angesiedelt ist: Sie ist an Menschen und manuelle Routinen gebunden, statt an die Plattform, auf der die Software läuft.

Was du zuerst ändern solltest: Kontrollmaßnahmen in die Plattformebene verlagern

Das Wichtigste auf einen Blick: Durch die Verlagerung der Kontrollmaßnahmen in die Plattform kannst du verifizierte Infrastrukturnachweise und einen automatischen Prüfpfad übernehmen, sodass der Infrastrukturanteil der Nachweise zu einem Nebenprodukt der Veröffentlichung wird und kein separates Projekt mehr ist.

Die erste Änderung besteht darin, Compliance-Kontrollen und -Nachweise aus manuellen Abläufen herauszulösen und in die Plattform zu verlagern, auf der deine Software läuft. Auf einer „Secure-by-Default“-Plattform werden die Kontrollen auf Infrastrukturebene von der Plattform selbst verwaltet und nachgewiesen, sodass du diesen Teil des Audits übernehmen kannst, anstatt ihn neu aufbauen zu müssen.

Dies funktioniert durch eine Aufteilung der gemeinsamen Verantwortung. Die Plattform sichert die Infrastruktur und protokolliert jede Änderung. Dein Team sorgt für die Sicherheit seines eigenen Programms und der Zugriffsrechte. Am Beispiel von Upsun Cloud sind die praktischen Auswirkungen dieses Modells folgende:

• Infrastrukturkontrollen sind bereits verifiziert. Die Bereitstellung auf zertifizierter Infrastruktur bedeutet, dass du ein Audit mit Infrastrukturkontrollen beginnst, die bereits von der Plattform verifiziert und dokumentiert wurden – du übernimmst also die Nachweise, anstatt sie neu zu erstellen. Upsun Cloud verfügt über die Zertifizierungen PCI DSS v4.0.1 Level 1, SOC 2 Typ 2 und ISO/IEC 27001:2022 und unterstützt HIPAA-regulierte Workloads im Rahmen einer unterzeichneten BAA. Der aktuelle Geltungsbereich und die Bedingungen sind im Trust Center aufgeführt.
• Jede Änderung wird automatisch protokolliert. Jede Bereitstellung und jede Konfigurationsänderung wird als Aktivität erfasst, sodass du über einen integrierten Prüfpfad verfügst, anstatt einen nachträglich zusammenstellen zu müssen.
• Die Konfiguration ist versionsverwalteter Code. Deine Umgebung wird in der Datei „.upsun/config.yaml“ und in allen anderen YAML-Dateien auf der obersten Ebene des Verzeichnisses „.upsun“ definiert. Der Git-Verlauf zeigt, wann jede Änderung vorgenommen wurde und was der Commit festgehalten hat, sodass du nicht mehr die Konsole durchgehen musst.
• Vorschau-Umgebungen werden anhand derselben Definition wie ihre übergeordnete Umgebung erstellt. Da jede Umgebung aus derselben Definition entsteht, ist der Nachweis, dass das, was du getestet hast, mit dem übereinstimmt, was du ausgeliefert hast, kein Aufwand mehr. Umgebungen erben zudem die Daten ihrer übergeordneten Umgebung; bereinige daher alle Datenbanken mit personenbezogenen Daten, bevor du eine Vorschau-Umgebung für einen breiteren Kreis freigibst.

Genau das ermöglichte es Qombo, einem EU-Fintech-Unternehmen, das Verifizierungs-APIs an Banken verkauft, in Gesprächen mit Banken glaubwürdig zu punkten: Durch die Übernahme der Compliance-Maßnahmen von Upsun Cloud und der EU-Datenresidenz verkürzten sich die Due-Diligence- und Compliance-Prüfungen, die seine Bankkunden daran durchführten, und ein zweiköpfiges Team erfüllte die Anforderungen auf Bankenniveau, ohne DevOps-Mitarbeiter einstellen zu müssen.

Das praktische Ergebnis sind einheitliche Nachweise über alle Umgebungen hinweg, ohne dass separate Konsolen manuell abgeglichen werden müssen. Das bedeutet nicht, dass Nachweise auf Knopfdruck erscheinen, und es entbindet dich nicht von der Verantwortung für das Programmieren deines eigenen Codes. Es bedeutet, dass der Infrastrukturteil der Arbeit übernommen wird, anstatt in jedem Zyklus neu aufgebaut zu werden.

Zwei Bedingungen solltest du frühzeitig klären. Die PCI-Zertifizierung von Upsun Cloud schließt derzeit die Regionen FR-1 und FR-3 aus; überprüfe daher den Status deiner Region, bevor du eine PCI-relevante Workload startest. HIPAA-Workloads laufen ausschließlich in der Region US-4 und erfordern eine unterzeichnete BAA.

So sieht ein Compliance-fähiger Release-Zyklus aus

Das Wichtigste auf einen Blick: Wenn Nachweise und Umgebungsparität automatisch erstellt werden, zwingen Audit-Fenster keinen Lieferstopp mehr auf.

Am deutlichsten lässt sich diese Veränderung anhand eines Releases kurz vor einem Audit erkennen.

Früher löste ein Release, das sich einem Audit-Zeitfenster näherte, hektisches Treiben aus. Entwickler unterbrachen die Arbeit an neuen Features, um Nachweise zusammenzustellen, abweichende Umgebungen abzugleichen und eine Aufzeichnung der Änderungen zu erstellen. Die Bereitstellung kam zum Stillstand – und dieser Stillstand dauerte so lange wie das Audit selbst.

Danach sind die Infrastrukturnachweise bereits vorhanden, da die Plattform jede Änderung sofort aufgezeichnet hat. Die Umgebungen stimmen bereits überein, da sie auf derselben Definition basieren. Das Audit stützt sich für diesen Teil der Arbeit auf das, was bereits vorhanden ist, und der Release-Rhythmus muss sich nicht mehr nach dem Audit-Kalender richten.

Das gleiche Muster zeigt sich bei den Vorabprüfungen, die ein reguliertes Team bei jedem Deployment durchführt. ROLLIN, eine Agentur, die für Kunden aus der Regierung und dem Gesundheitswesen entwickelt, ersetzte langsame, manuelle und fehleranfällige Validierungen durch eine automatisierte Pipeline, die mit versionskontrollierten Upsun-cloud-Umgebungen verknüpft ist, und wechselte zu schnelleren, sichereren und zuverlässigeren Releases, ohne dabei das Auslieferungsrisiko zu erhöhen.

Wo du anfangen solltest: Verlege die Compliance in die Plattform

Dass Compliance deine Releases verlangsamt, ist ein Zeichen dafür, dass die Compliance-Arbeit auf der falschen Ebene angesiedelt ist – nicht, dass dein Team zu langsam wäre. Der erste Schritt besteht darin, die Infrastrukturkontrollen und ihre Nachweise in die Plattform zu verlagern, sodass dieser Teil der Compliance automatisch übernommen und generiert wird, anstatt in jedem Zyklus von Hand neu erstellt zu werden.

Audits sind der offensichtlichste Weg, auf dem Compliance die Bereitstellung verlangsamt, aber nicht der einzige. Regulierte Teams sehen sich mit ähnlichen Anforderungen konfrontiert, wie beispielsweise der EU-Richtlinie DORA, bei der die Einschränkung architektonischer Natur ist: Ihr müsst nachweisen, dass ihr zu einem anderen Anbieter wechseln könnt, ohne das System neu zu gestalten. Hier gilt dieselbe Lösung, da eine portierbare, versionskontrollierte Konfiguration dieser Ausstiegsstrategie eine konkrete Grundlage bietet. 

Unser Beitrag zur DORA-Ausstiegsstrategie behandelt das Thema ausführlich.

Häufig gestellte Fragen (FAQ)

Muss Compliance Software-Releases verlangsamen?
Nein. Releases verlangsamen sich, wenn Compliance-Nachweise manuell gesammelt und bei jedem Audit-Zyklus wiederholt werden. Wenn Infrastrukturkontrollen in der Plattform integriert sind und Nachweise automatisch bei Änderungen erfasst werden, führt dieser Teil der Audit-Vorbereitung nicht mehr zu einer Zwangspause bei der Bereitstellung.

Warum verlangsamen Audits die Arbeit der Entwicklerteams?
Weil Audits die Entwickler von der Entwicklung von Features abziehen, damit sie manuell Nachweise erstellen: Screenshots sammeln, Konfigurationen überprüfen und nachweisen, dass die Staging-Umgebung mit der Produktivumgebung übereinstimmt. Die Verzögerung entsteht durch die manuelle Nachweisarbeit, nicht dadurch, wie schnell das Team programmiert.

Was ist „inherited compliance“?
Es ist ein Modell, bei dem eine standardmäßig sichere Plattform die Kontrollen auf Infrastrukturebene verwaltet und nachweist, sodass dein Team für den eigenen Anwendungscode, die Zugriffskontrolle und den Datenumgang verantwortlich ist. Du beginnst ein Audit damit, dass dieser Teil des Kontrollsatzes bereits verifiziert und dokumentiert ist, anstatt ihn erst nachträglich rekonstruieren zu müssen.

Kannst du die PCI-DSS- oder SOC-2-Anforderungen erfüllen, ohne die Bereitstellung zu verlangsamen?
Du kannst den Teil der Audit-Arbeit, der sich auf den Nachweis der Infrastruktur bezieht, eliminieren, indem du auf bereits zertifizierter Infrastruktur bereitstellst und die Plattform den Prüfpfad erstellen lässt. Das reduziert den manuellen Aufwand für den Nachweis und schränkt den Umfang des Audits ein, obwohl dein Programmcode, deine Zugriffskontrollen und dein Datenumgang weiterhin in deiner Verantwortung liegen.

Wie wirkt sich DORA auf die Entwicklungsarbeit von Finanzdienstleistungsteams aus?
Gemäß Artikel 28(8) verpflichtet DORA Finanzunternehmen dazu, dokumentierte Ausstiegsstrategien für IKT-Dienste einzuführen, die kritische oder wichtige Funktionen unterstützen, und diese regelmäßig zu testen und zu überprüfen. Das ist schwer nachzuweisen, wenn Bereitstellungen an anbieterspezifische Dienste gebunden sind. Eine portierbare, versionskontrollierte Konfiguration gibt den Teams einen konkreten Ausstiegsplan an die Hand, wobei eine vollständige Ausstiegsstrategie jedoch auch eine Migrationsplanung erfordert.